<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0038)http://www.mcc.ac.uk/grub/grub_24.html -->
<HTML>
<!-- Mirrored from bos.asmhackers.net/docs/partition tables/GRUB Manual - The format of partition table.htm by HTTrack Website Copier/3.x [XR&CO'2013], Tue, 07 Oct 2014 11:06:55 GMT -->
<HEAD><TITLE>GRUB Manual - The format of partition table</TITLE>
<META content="text/html; charset=windows-1252" http-equiv=Content-Type><!-- Created by texi2html 1.56k from grub.texi on 14 July 2000 -->
<META content="MSHTML 5.00.2614.3500" name=GENERATOR></HEAD>
<BODY>Go to the <A href="http://www.mcc.ac.uk/grub/grub_1.html">first</A>, <A 
href="http://www.mcc.ac.uk/grub/grub_23.html">previous</A>, <A 
href="http://www.mcc.ac.uk/grub/grub_25.html">next</A>, <A 
href="http://www.mcc.ac.uk/grub/grub_28.html">last</A> section, <A 
href="http://www.mcc.ac.uk/grub/grub_toc.html">table of contents</A>. 
<P>
<HR>

<P>
<H1><A href="http://www.mcc.ac.uk/grub/grub_toc.html#TOC63" name=SEC63>The 
format of partition table</A></H1>
<H2><A href="http://www.mcc.ac.uk/grub/grub_toc.html#TOC64" name=SEC64>Overview 
the partition table</A></H2>
<P>FDISK creates all partition records (sectors). The primary purpose of a 
partition record is to hold a partition table. The rules for how FDISK works are 
unwritten but so far most FDISK programs seem to follow the same basic idea. 
<P>First, all partition table records (sectors) have the same format. This 
includes the partition table record at cylinder 0, head 0, sector 1 -- what is 
known as the Master Boot Record (MBR). The last 66 bytes of a partition table 
record contain a partition table and a 2 byte signature. The first 446 bytes of 
these sectors usually contain a program but only the program in the MBR is ever 
executed (so extended partition table records could contain something other than 
a program in the first 466 bytes). For more information, see section <A 
href="http://www.mcc.ac.uk/grub/grub_23.html#SEC62">The structure of Master Boot 
Record</A>. 
<P>Second, extended partitions are <EM>nested</EM> inside one another and 
extended partition table records form a <EM>linked list</EM>. I will attempt to 
show this in a diagram at section <A 
href="http://www.mcc.ac.uk/grub/grub_24.html#SEC66">The format of the table 
entry</A>. 
<P>Each partition table entry is 16 bytes and contains things like the start and 
end location of a partition in CHS, the start in LBA, the size in sectors, the 
partition <EM>type</EM> and the <EM>active</EM> flag. Older versions of FDISK 
may compute incorrect LBA or size values. And when your computer boots itself, 
only the CHS fields of the partition table entries are used (another reason LBA 
doesn't solve the &gt;528MB problem). The CHS fields in the partition tables are 
in L-CHS format, see section <A 
href="http://www.mcc.ac.uk/grub/grub_22.html#SEC59">CHS addressing and LBA 
addressing</A>. 
<H2><A href="http://www.mcc.ac.uk/grub/grub_toc.html#TOC65" name=SEC65>The list 
of the <EM>type</EM> code</A></H2>
<P>There is no central clearing house to assign the codes used in the one byte 
<EM>type</EM> field. But codes are assigned (or used) to define most every type 
of file system that anyone has ever implemented on the x86 PC: 12-bit FAT, 
16-bit FAT, HPFS, NTFS, etc. Plus, an extended partition also has a unique type 
code. 
<P>In the FDISK program <SAMP>`sfdisk'</SAMP>, the following list is assumed: 
<DL compact>
  <DT>00 
  <DD>Empty 
  <DT>01 
  <DD>DOS 12-bit FAT 
  <DT>02 
  <DD>XENIX / 
  <DT>03 
  <DD>XENIX /usr 
  <DT>04 
  <DD>DOS 16-bit FAT &lt;32M 
  <DT>05 
  <DD>DOS Extended 
  <DT>06 
  <DD>DOS 16-bit FAT &gt;=32M 
  <DT>07 
  <DD>HPFS / NTFS 
  <DT>08 
  <DD>AIX boot or SplitDrive 
  <DT>09 
  <DD>AIX data or Coherent 
  <DT>0A 
  <DD>OS/2 Boot Manager 
  <DT>0B 
  <DD>Windows95 FAT32 
  <DT>0C 
  <DD>Windows95 FAT32 (LBA) 
  <DT>0E 
  <DD>Windows95 FAT16 (LBA) 
  <DT>0F 
  <DD>Windows95 Extended (LBA) 
  <DT>10 
  <DD>OPUS 
  <DT>11 
  <DD>Hidden DOS FAT12 
  <DT>12 
  <DD>Compaq diagnostics 
  <DT>14 
  <DD>Hidden DOS FAT16 
  <DT>16 
  <DD>Hidden DOS FAT16 (big) 
  <DT>17 
  <DD>Hidden HPFS/NTFS 
  <DT>18 
  <DD>AST Windows swapfile 
  <DT>24 
  <DD>NEC DOS 
  <DT>3C 
  <DD>PartitionMagic recovery 
  <DT>40 
  <DD>Venix 80286 
  <DT>41 
  <DD>Linux/MINIX (sharing disk with DRDOS) 
  <DT>42 
  <DD>SFS or Linux swap (sharing disk with DRDOS) 
  <DT>43 
  <DD>Linux native (sharing disk with DRDOS) 
  <DT>50 
  <DD>DM (disk manager) 
  <DT>51 
  <DD>DM6 Aux1 (or Novell) 
  <DT>52 
  <DD>CP/M or Microsoft SysV/AT 
  <DT>53 
  <DD>DM6 Aux3 
  <DT>54 
  <DD>DM6 
  <DT>55 
  <DD>EZ-Drive (disk manager) 
  <DT>56 
  <DD>Golden Bow (disk manager) 
  <DT>5C 
  <DD>Priam Edisk (disk manager) 
  <DT>61 
  <DD>SpeedStor 
  <DT>63 
  <DD>GNU Hurd or Mach or Sys V/386 (such as ISC UNIX)<A 
  href="http://www.mcc.ac.uk/grub/grub_foot.html#FOOT14" name=DOCF14>(14)</A> 
  <DT>64 
  <DD>Novell Netware 286 
  <DT>65 
  <DD>Novell Netware 386 
  <DT>70 
  <DD>DiskSecure Multi-Boot 
  <DT>75 
  <DD>PC/IX 
  <DT>77 
  <DD>QNX4.x 
  <DT>78 
  <DD>QNX4.x 2nd part 
  <DT>79 
  <DD>QNX4.x 3rd part 
  <DT>80 
  <DD>MINIX until 1.4a 
  <DT>81 
  <DD>MINIX / old Linux 
  <DT>82 
  <DD>Linux swap 
  <DT>83 
  <DD>Linux native<A href="http://www.mcc.ac.uk/grub/grub_foot.html#FOOT15" 
  name=DOCF15>(15)</A> 
  <DT>84 
  <DD>OS/2 hidden C: drive 
  <DT>85 
  <DD>Linux extended 
  <DT>86 
  <DD>NTFS volume set 
  <DT>87 
  <DD>NTFS volume set 
  <DT>93 
  <DD>Amoeba 
  <DT>94 
  <DD>Amoeba BBT 
  <DT>A0 
  <DD>IBM Thinkpad hibernation 
  <DT>A5 
  <DD>BSD/386 
  <DT>A7 
  <DD>NeXTSTEP 486 
  <DT>B7 
  <DD>BSDI fs 
  <DT>B8 
  <DD>BSDI swap 
  <DT>C1 
  <DD>DRDOS/sec (FAT-12) 
  <DT>C4 
  <DD>DRDOS/sec (FAT-16, &lt; 32M) 
  <DT>C6 
  <DD>DRDOS/sec (FAT-16, &gt;= 32M) 
  <DT>C7 
  <DD>Syrinx 
  <DT>DB 
  <DD>CP/M or Concurrent CP/M or Concurrent DOS or CTOS 
  <DT>E1 
  <DD>DOS access or SpeedStor 12-bit FAT extended partition 
  <DT>E3 
  <DD>DOS R/O or SpeedStor 
  <DT>E4 
  <DD>SpeedStor 16-bit FAT extended partition &lt; 1024 cyl. 
  <DT>F1 
  <DD>SpeedStor 
  <DT>F2 
  <DD>DOS 3.3+ secondary 
  <DT>F4 
  <DD>SpeedStor large partition 
  <DT>FE 
  <DD>SpeedStor &gt;1024 cyl. or LANstep 
  <DT>FF 
  <DD>Xenix Bad Block Table </DD></DL>
<H2><A href="http://www.mcc.ac.uk/grub/grub_toc.html#TOC66" name=SEC66>The 
format of the table entry</A></H2>
<P>The 16 bytes of a partition table entry are used as follows: <PRE>    +--- Bit 7 is the active partition flag, bits 6-0 are zero.
    |
    |    +--- Starting CHS in INT 13 call format.
    |    |
    |    |      +--- Partition type byte.
    |    |      |
    |    |      |    +--- Ending CHS in INT 13 call format.
    |    |      |    |
    |    |      |    |        +-- Starting LBA.
    |    |      |    |        |
    |    |      |    |        |       +-- Size in sectors.
    |    |      |    |        |       |
    v &lt;--+---&gt;  v &lt;--+--&gt;     v       v

   0  1  2  3  4  5  6  7  8 9 A B  C D E F
   DH DL CH CL TB DL CH CL LBA..... SIZE....

   80 01 01 00 06 0e be 94 3e000000 0c610900  1st entry

   00 00 81 95 05 0e fe 7d 4a610900 724e0300  2nd entry

   00 00 00 00 00 00 00 00 00000000 00000000  3rd entry

   00 00 00 00 00 00 00 00 00000000 00000000  4th entry
</PRE>
<P>Bytes 0-3 are used by the small program in the Master Boot Record to read the 
first sector of an active partition into memory. The <EM>DH</EM>, <EM>DL</EM>, 
<EM>CH</EM> and <EM>CL</EM> above show which x86 register is loaded when the MBR 
program calls INT 13H AH=02h to read the active partition's boot sector. For 
more information, see section <A 
href="http://www.mcc.ac.uk/grub/grub_23.html#SEC62">The structure of Master Boot 
Record</A>. 
<P>These entries define the following partitions: 
<OL>
  <LI>The first partition, a primary partition DOS FAT, starts at CHS 0H,1H,1H 
  (LBA 3EH) and ends at CHS 294H,EH,3EH with a size of 9610CH sectors. 
  <LI>The second partition, an extended partition, starts at CHS 295H,0H,1H (LBA 
  9614AH) and ends at CHS 37DH,EH,3EH with a size of 34E72H sectors. 
  <LI>The third and fourth table entries are unused. </LI></OL>
<H2><A href="http://www.mcc.ac.uk/grub/grub_toc.html#TOC67" name=SEC67>Some 
basic rules for partition table</A></H2>
<P>Keep in mind that there are <EM>no</EM> written rules and <EM>no</EM> 
industry standards on how FDISK should work but here are some basic rules that 
seem to be followed by most versions of FDISK: 
<OL>
  <LI>In the MBR there can be 0-4 <EM>primary</EM> partitions, OR, 0-3 primary 
  partitions and 0-1 extended partition entry. 
  <LI>In an extended partition there can be 0-1 <EM>secondary</EM> partition 
  entries and 0-1 extended partition entries. 
  <LI>Only 1 primary partition in the MBR can be marked <EM>active</EM> at any 
  given time. 
  <LI>In most versions of FDISK, the first sector of a partition will be aligned 
  such that it is at head 0, sector 1 of a cylinder. This means that there may 
  be unused sectors on the track(s) prior to the first sector of a partition and 
  that there may be unused sectors following a partition table sector. For 
  example, most new versions of FDISK start the first partition (primary or 
  extended) at cylinder 0, head 1, sector 0. This leaves the sectors at cylinder 
  0, head 0, sectors 2...n as unused sectors. This same layout may be seen on 
  the first track of an extended partition. See example 2 below. Also note that 
  software drivers like Ontrack's Disk Manager depend on these unused sectors 
  because these drivers will <EM>hide</EM> their code there (in cylinder 0, head 
  0, sectors 2...n). This is also a good place for boot sector virus programs to 
  hang out. 
  <LI>The partition table entries (slots) can be used in any order. Some 
  versions of FDISK fill the table from the bottom up and some versions of FDISK 
  fill the table from the top down. Deleting a partition can leave an unused 
  entry (slot) in the middle of a table. 
  <LI>And then there is the <EM>hack</EM> that some newer OS's (OS/2 and Linux) 
  use in order to place a partition spanning or passed cylinder 1024 on a system 
  that does not have a CHS translating BIOS. These systems create a partition 
  table entry with the partition's starting and ending CHS information set to 
  all FFH. The starting and ending LBA information is used to describe the 
  location of the partition. The LBA can be converted back to a CHS -- most 
  likely a CHS with more than 1024 cylinders. Since such a CHS can't be used by 
  the system BIOS, these partitions can not be booted or accessed until the OS's 
  kernel and hard disk device drivers are loaded. It is not known if the systems 
  using this <EM>hack</EM> follow the same rules for the creation of these type 
  of partitions. </LI></OL>
<P>There are <EM>no</EM> written rules as to how an OS scans the partition table 
entries so each OS can have a different method. For DOS, this means that 
different versions could assign different drive letters to the same FAT file 
system partitions. 
<P>@unnumbered{Appendices and Indices} 
<P>
<HR>

<P>Go to the <A href="http://www.mcc.ac.uk/grub/grub_1.html">first</A>, <A 
href="http://www.mcc.ac.uk/grub/grub_23.html">previous</A>, <A 
href="http://www.mcc.ac.uk/grub/grub_25.html">next</A>, <A 
href="http://www.mcc.ac.uk/grub/grub_28.html">last</A> section, <A 
href="http://www.mcc.ac.uk/grub/grub_toc.html">table of contents</A>. 
</P></BODY>
<!-- Mirrored from bos.asmhackers.net/docs/partition tables/GRUB Manual - The format of partition table.htm by HTTrack Website Copier/3.x [XR&CO'2013], Tue, 07 Oct 2014 11:06:55 GMT -->
</HTML>
